1. Field of the Invention
The present invention is directed to a secure virtual tape management system with early read options. In particular, the present invention is directed to a secure virtual tape management system capable of allowing host systems to read data from a virtual tape almost immediately after the process of writing the virtual tape has been initiated and before writing of the virtual tape has been completed. Additionally, the present invention affords the ability for multiple hosts to simultaneously and independently read the tape's data, each at its own pace.
2. Prior Art
It is necessary to store and backup data for many mainframe computer installations primarily for the purpose of safekeeping critical information in the event of an unexpected loss of the primary copy. The backups are often remotely stored offsite from the location of the mainframe installation.
At one time, ten inch, round reel tape drives were utilized on mainframe installations. The well known tape itself consists of a thin plastic base material with a coating of ferromagnetic ferric oxide powder. The round reel tapes were physically transported to an offsite location. Periodically, the tapes would be returned and then reused.
In the 1980's, cartridge tape units replaced the round reel tape drives. The tape cartridge system had fewer moving parts and was less prone to failure. Additionally, the tape cartridge system occupies a smaller floor footprint and consumed less power than the round reel drives. Additionally, the media itself was improved over time. Denser recording techniques allowed the cartridges to be smaller, yet hold the same amount of data. To improve cataloging and indexing functions, and facilitate data accessibility, typically one data set is placed on one tape volume. Some tape data sets span multiple volumes while others occupy less than a single volume. This can result in a significant waste of tape as most data sets occupy only a small portion of the media and the rest of the volume remains unused. Estimates are that industry norms are for tape cartridges to be less than 50% utilized. With a cartridge tape system, the same procedures for physically pulling certain cartridges and moving them to an offsite location would be performed.
More recently, virtual tape servers have been introduced which place a controller between a mainframe and the cartridge tape devices and attach a disk cache area from and to which data can be read and written. The controller handles the migration of data between the disk cache and the tape media in an optimal space and time fashion. The data is actually being read from and to disks. The disks are typically faster than tape devices.
Information regarding tape volumes is stored in a tape catalog, maintained by a tape management system running on the host mainframe. The tape management system associates a particular tape using its primary identifier, the tape's volume serial number, with the data sets stored onto it along with its retention, or expiration date. In order to manage the re-use of tapes, the retention date indicates when the data on a tape is no longer required and at such point in time, the tape may have its data overwritten or “scratched” out. Scratch tape is a common mainframe term for a tape available to be written upon, regardless of its prior contents if any.
A scratch list is a report that is generally prepared on a daily basis that includes all of the volume serial numbers whose retention date expired on that day. A human typically refers to this report while walking through a tape library, pulling those tapes on the report so that they may be placed into the scratch pool for reuse. The tape management system imposes a safe guard against non-expired tapes being mounted in place of a scratch tape by comparing the tape's volume serial number against its catalog expiration date. This volume serial number, in addition to being hand written onto the exterior of the tape, is on the beginning of the tape prior to the start of data set information in a section known as a “header”. When a scratch tape is mounted for writing, the tape management system inspects the tape catalog to verify that the tape is truly a scratch. If not, then it is rejected and a different scratch tape requested.
A vault list is a report prepared at some particular time interval that includes all of the volume serial numbers that are to be removed from the tape library and physically taken offsite. Mainframe data centers have the need to move or copy data to off site locations, primarily for the purpose of safe keeping critical information to be used in the event of an unexpected loss of the primary copy of that information. This typically involves physical transportation of the mainframe tapes, an error prone process in that sometimes all the required tapes are not sent or sometimes a tape sent in error that is later required to be retrieved in order to complete the processing of a mainframe job. Further, the data on these tapes is typically un-encrypted and therefore vulnerable to anyone being able to read it.
The tape management system is primarily used to cross-reference the location of a desired data set to a tape volume serial number. It is secondarily used to manage scratch lists and vault lists.
The present invention is supported via an encrypted communications protocol interfacing with, and relying upon, the teachings, practices and claims disclosed in U.S. Pat. No. 6,499,108 (hereinafter synonymously referred to as “Secure Agent®” or “SA”), which is incorporated herein by reference.
Secure Agent Overview
The following overview is provided to facilitate a comprehensive understanding of the teachings of the instant invention. Secure Agent® utilizes a secure login sequence wherein a client connects to a Secure Agent server using a key known to both systems and a client connects and presents the server with user identification (as used herein the term “client” refers synonymously to a remote user or component establishing, and communicating with the instant invention through Secure Agent allocation and encryption processes as taught in the above noted applications). If recognized, the Secure Agent server initiates a protocol whereby the client's identification is verified and subsequent communication is conducted within a secured (encrypted) construct. For purposes of this overview, the term “server” should be considered a hardware configuration represented as a central processing unit wherein Secure Agent, a Host DLL and driver reside, and are executed. The term “DLL” as used herein refers to a Secure Agent host dynamically linked library (a.k.a. Host DLL). The term “DLL” or “dynamically linked library” is used in a manner consistent with that known to those skilled in the art. Specifically, the term “DLL” refers to a library of executable functions or data that can be used by a Windows™ or LINUX application. As such, the instant invention provides for one or more particular functions and program access to such functions by creating a static or dynamic link to the DLL of reference, with “static links” remaining constant during program execution and “dynamic links” created by the program as needed.
The Secure Agent® server presents a variable unit of data, such as the time of day, to the client as a challenge. The client must then encrypt that data and supply it back to the server. If the server is able to decrypt the data using the stored client's key so that the result matches the original unencrypted challenge data, the user is considered authenticated and the connection continue. The key is never passed between the two systems and is therefore never at risk of exposure.
The initial variable unit of data seeds the transmission of subsequent data so that the traffic for each client server session is unique. Further, each byte of data transmitted is influenced by the values of previously sent data. Therefore, the connection is secure across any communication passageway including public networks such as, but not limited to, the Internet. The distance between the client and server is not of consequence but is typically a remote connection. For accountability purposes, the actions of a client may be recorded (logged) to non-volatile storage at almost any detail level desired.
The access rights of each client (what the client is able to accomplish during a session) is governed by data stored on the Secure Agent® server to which the client is associated. As an example, such rights might encompass the ability to administer and utilize the services of the server system, which would, in turn, include capabilities such as adding new clients or components, changing a user's rights, transferring new code to the server, using a feature (or service) of the server and more.
Consequently, Secure Agent® allows for the transmission of new code to the server and for that code to be implemented upon demand by a client. Such dynamic, real-time implementation in turn, allows for the behavior of the server to be modified. It is to this behavior modification the instant invention addresses its teachings, and thereby advances the contemporary art.
As will be readily appreciated by those skilled in the art, though the instant invention utilizes encryption/decryption and code recognition technology associated with Secure Agent®, alternative technologies may be employed in support of the instant invention without departing from the disclosure, teachings and claims presented herein.
Virtual Tape Catalog
A virtual tape catalog described in the present invention is a database repository of tape related information regarding each virtual tape used by the tape emulator. It is used to manage the disposition of tapes and is therefore much like a mainframe's internal tape catalog. The virtual tape catalog is crucial to the operation of the system and is therefore replicated to one or more remote locations. Along with the primary data element used to identify a specific virtual tape, the volume serial number, it indicates the information necessary to manage it such as:                Expiration date.        Scratch indicator.        Indicator that it should always be copied to remote data storage.        Indicator that it is ready to be copied to remote data storage.        The remote data storage target to which it should be copied.        Indicator that the source tape file should be deleted after being copied to remote data storage (a move operation).        Indicator that it should always be copied to an archiver.        Indicator that it is ready to be copied to an archiver.        The archiver target to which it should be copied.        Indicator that the source tape file should be deleted after being copied to an archiver (a move operation).        The host processor dataset names that it contains.        The size of the tape file.        The date and time when it was created.        The date and time when it was last accessed.        The current locations of the tape file.        The date and time that it was transmitted to its current locations.        An indicator that it is currently in use.        The security groups to which it belongs.        Indicator that the tape file should be automatically retrieved upon a mount request if it happens to have been moved off the tape emulator component.        Indicates that it should be recovered to the tape emulator component.        Indicates it should be encrypted when created.        Encrypted indicator.        
In addition to information specific to each tape, additional information is stored within the virtual tape catalog such as global configuration information and rules that govern the disposition of tapes. These include:                The central key phrase (password) used to encrypt the virtual tape images.        Certain dataset name patterns that, when encountered during the creation of a tape, cause a tape to be reassigned into specific security groups.        Periods of time that, when compared against when a tape is to be expired during the creation of a tape, cause a tape to be copied to remote data storage.        Periods of time that, when compared against when a tape is to be expired during the creation of a tape, cause a tape to be copied to an archiver.        Periods of time that, if a tape goes unaccessed by the host processor, that it will be moved to remote data storage.        Periods of time that, if a tape goes unaccessed by the host processor, that it will be moved to the archiver.        
The invention's mainframe host information component provides tape catalog and tape mount information from the host processor by way of one of the tape emulator component's devices. The specific device may be any device type best suited for the facilities available to the host information component. Non-limiting examples include 3480, through special commands or sequences; 3286 printer emulation; or 3270 display emulation. Based on a unique communication sequence initiated by the host information component, this particular emulated device is able to recognize that it services the ‘control path’ and reacts accordingly.
The ‘control path’ between the mainframe host information component and the remainder of elements of the system is used to supply all information required from the mainframe host such as tapes to be scratched, tapes to be transmitted to vault, tape mount requests and tape retrieval (or recall) requests. The information relating to tape scratches, tape vaulting and tape retrieval is collected periodically by the host information component from the host processor's tape catalog. The information relating to tape mount requests is collected as they occur, either by intercepting an operator message or by otherwise hooking into a host processor's tape mount user exit, a method by which a utility may gain useful information. For a tape to be scratched, vaulted or recalled, the device correspondingly updates the virtual tape catalog. For a tape to be mounted, the device relays the mount request to the emulated tape drive indicated in the request, parsing the request as necessary per the host processor's tape mount request message format. If, for whatever reason, the tape mount cannot be satisfied, a message is sent up through the control path to the host information component in order that an operator message may be issued indicating the reason for being unable to service the request.
It is occasionally necessary for a secondary host system to read a tape produced by a primary host system as soon as possible, with perhaps time-critical processing by the secondary host system being delayed until it is able to process the primary host's tape. This has historically required that the first host processor complete writing the entirety of the necessary data to tape, unload the tape, have the tape manually transported to the secondary host's location then be mounted on one of the secondary host's tape drives. Often, by design, there is some distance between the two systems causing further time delay during transportation. Even in the case with existing emulated tape systems, the data on the first tape must be completed prior to initiating the reading of the tape by a secondary system.
Accordingly, it is a principal object and purpose of the present invention to provide a secure virtual tape management system capable of allowing the sharing of a virtual tape to one or more secondary hosts almost immediately after the process of writing the virtual tape has been initiated by the primary host, well before the writing of the first tape has been completed.